Database access security

ABSTRACT

Apparatus for protection of database objects from unwanted access, particularly from external connections via a firewall ( 20 ). The apparatus comprises a data packet parsing unit ( 54 ) for parsing a data packet to find database operation commands in the packet, and an enforcement unit ( 56 ) for applying enforcement rules to the data packet, thereby to protect respective database objects. The apparatus may form an additional layer ( 50, 52 ) of protection in conjunction with a firewall ( 20 ) to protect internal data.

FIELD OF THE INVENTION

The present invention relates to database access security and moreparticularly but not exclusively to a method or apparatus for securingdatabase material against unauthorized access from an external networkwhilst at the same time permitting legitimate access from the externalnetwork. Examples of database systems of interest are MS-SQL Server,Oracle, DB2 and UDB.

BACKGROUND OF THE INVENTION

Networks typically require users to log on, that is give usernames andpasswords to gain access. Based on the username the network may decideon a level of access. Local Area Networks are typically connected to theoutside world and often have a firewall to protect the perimiter of theLAN from external intrusions. The firewall may permit users to log infrom outside the LAN. Such users are hereinafter referred to as externalusers, by contrast with internal users, whose connections are fromwithin the perimeter of the LAN. The firewall may apply restrictions tosuch external users, or may not allow them at all, and the firewall mayalso monitor and control e-mail, web-interaction and the like.Typically, in the case of the external user, the firewall may check theusername at the periphery and decide what access level to provide. Thefirewall may specify particular machines on the LAN to which theexternally connecting user is permitted access, or it may providegeneral access, but once access to a machine is granted, the access isunrestricted. The firewall does not monitor, validate or in any otherway consider actual usage, except in the case of widely known protocols,as discussed below.

Today, an organization's information systems are often prime targets forvandalism and theft, and organizations are especially concerned aboutthe activities performed by external users. Loss or corruption of adatabase can be catastrophic for an organization, and information in thedatabase can be of use to rivals. A database that includes customers'credit card numbers, or staff bank account numbers, can be of greatinterest to thieves. Currently, external users are able to log in, andthe resulting access connection is assigned use rights associated withthe logged in user. On the one hand, the organization wishes to allowstaff to be able to work from home or have access to the LAN whilsttraveling etc. yet at the same time free external access gives rise tothreats of the kind described above. It is a goal of firewall technologyto provide maximal levels of security for minimal levels ofinconvenience, and one way of achieving this goal is to target accessrestrictions as closely as possible to the kind of activity whichconstitutes the threat, leaving non-threat bearing activity to continueunimpeded.

To reduce possible threats, organizations are therefore moving toimplement application specific security that can monitor the actualactivity of external users and block activity that is suspicious,thereby to protect against intrusion from outside the LAN that isapplication specific. Software packages that provide data usesurveillance already exist on the market. However, the existing packagesare restricted to well known and standardized protocols such as HTTP,SMTP and FTP. These packages are able to identify the use of theparticular protocol and use their knowledge of the protocol to monitorand control the content. Databases however, do not use any singlerecognized protocol. Indeed most database packages are not accompaniedby any published protocol and most database versions, even from the samesource, include variations in the protocol used. There is thus noapplication specific security package that is currently aimed atdatabases, and it is not currently possible to carry out content basedmonitoring and control of database queries or results.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a data security layerthat monitors and/or controls database access statements or commands,for example the actual SQL statements that constitute much databaseactivity for users and application servers. As mentioned above, typicaldatabase systems include MS-SQL Server, Oracle, DB2 and UDB.

According to a first aspect of the present invention there is thusprovided apparatus for protection of database objects from unwantedaccess comprising:

a data packet inspection unit for inspecting passing data packets tofind and carry out an analysis of database operation text within saidpacket,

and an enforcement unit, associated with said data packet inspectionunit for applying enforcement rules to said data packet, based at leastpartly on said analysis, thereby to protect respective database objects.

Preferably, said data inspection unit comprises a packet analysis unitto look for structure associated with database operation text, and aparsing unit, associated with said search unit to parse said databaseoperation text into underlying statements comprising at least databaseoperation commands and database objects.

Preferably, said data packet inspection unit is configurable inassociation with a firewall between an external network and an internalLAN containing said database objects, thereby to guard a respectivedatabase.

Preferably, said inspection unit is configurable to be positionedbetween two LANs.

Preferably, said data packet inspection unit is further operable to findinformation regarding sources of respective data packets and regardingdata objects of respective commands.

Preferably, said enforcement rules each comprise at least one condition,said condition being the presence in the database operation text of apredetermined database operation command.

Preferably, said enforcement rules each comprise at least one condition,said condition being the presence in the database operation text of anyone of a group of database operation commands belonging to apreformulated group.

Preferably, said wherein said enforcement rules each comprise at leastone condition, said condition being the specification within thedatabase operation text of a predetermined database object.

Preferably, said enforcement rules each comprise at least one condition,said condition being the specification. within the database operationtext of any one of a group of database objects belonging to apreformulated group.

The apparatus may further comprise a management module for setting saidenforcement rules.

Preferably, said management module is further operable to define groupsof database commands, said groups being usable to define said rules.

Preferably, said management module is accessible via a graphical userinterface.

Preferably, said management module is operable to set an access policycomprising a plurality of rules, each rule specifying a group ofcommands, a group of users and a group of data objects, said accesspolicy being transferable to said rule application unit.

Preferably, at least some of said enforcement rules define loggingactivities and said enforcement unit further comprises loggingfunctionality therefore.

Preferably, said inspecting comprises obtaining a signature from saiddatabase operation text and wherein at least some of said rules relateat least in part to said signatures.

According to a second preferred embodiment of the present inventionthere is provided a method for protection of database objects fromunwanted access comprising:

parsing a data packet to find database operation commands in saidpacket, and applying enforcement rules to said data packet, said rulesspecifying conditions based at least partially on said databaseoperation commands, thereby to protect respective database objects.

The method may further comprise finding information regarding sources ofrespective data packets and regarding data objects of respectivecommands.

Preferably, said finding information regarding sources of respectivedata packets is carried out per user connection, the method furthercomprising associating said sources with data packets of said userconnection.

The method may further comprise applying said enforcement rulesselectively to said data packets, depending on information found inrespective data packets by said parsing units.

Preferably, said database operation commands are arranged in groups andwherein said rules relate to said groups.

Preferably, said command sources are arranged in groups and said rulesrelate to said groups.

Preferably, said database objects are arranged in groups and whereinsaid rules relate to said groups.

The method may further comprise arranging said database commands intogroups and using said groups to define said rules.

The method may further comprise forming an access policy by arrangingtogether a plurality of rules for use.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the invention and to show how the same maybe carried into effect, reference will now be made, purely by way ofexample, to the accompanying drawings.

With specific reference now to the drawings in detail, it is stressedthat the particulars shown are by way of example and for purposes ofillustrative discussion of the preferred embodiments of the presentinvention only, and are presented in the cause of providing what isbelieved to be the most useful and readily understood description of theprinciples and conceptual aspects of the invention. In this regard, noattempt is made to show structural details of the invention in moredetail than is necessary for a fundamental understanding of theinvention, the description taken with the drawings making apparent tothose skilled in the art how the several forms of the invention may bcembodied in practice. In the accompanying drawings:

FIG. 1 is a generalized schematic diagram illustrating a general conceptof a first preferred embodiment of the present invention,

FIG. 2 is a simplified schematic diagram showing a second preferredembodiment of the present invention, in which an SQL filter is locatedinwards of a DMZ, the DMZ having a database query application,

FIGS. 3A, 3B and 3C are simplified schematic diagrams of three versionsof the embodiment of FIG. 2, in which the elements of the embodiment ofFIG. 2 are mapped onto a series of servers,

FIG. 4 is a simplified schematic diagram showing in greater detail theSQL filter of FIGS. 1-3,

FIG. 5 is a generalized screen shot showing a dialog window for settingup a rule for the filter of FIG. 4,

FIG. 6 is a generalized schematic diagram showing network configurationfor the SQL filter of FIG. 4 and illustrating a management console forprogramming the filter,

FIG. 7 is a generalized screen shot showing a dialog window forestablishing a security policy for the filter of FIG. 4 by insertion ofrules,

FIG. 8 is a simplified flow chart showing the process of creating apolicy for use in the filter of FIG. 4.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present embodiments provide a system for monitoring and orcontrolling database command statements as they pass in to a LAN from anexternal connection. The commands used may be monitored by theembodiments as well as the source of the commands and the data objectsto which the commands apply. Rules and policies define legitimate andillegitimate activity by using the various commands, sources andobjects, so that for example different grades of data can be protectedfrom different types of uses by different users or categories of user.In the present embodiments, protection is not provided by accesspermissions assigned following log-in operations, but rather by theactual data as found in the individual data packet, in particular by thedatabase access or operational commands, especially SQL commands. Thus,non-database activity is not affected by the embodiments andfurthermore, database restrictions can be made as specific as possibleso as to target threats with as little effect as possible on legitimatedatabase activity.

The embodiments described herein are for use together with a firewall,although additional embodiments that may be used on their own to providedatabase protection are contemplated.

Before explaining at least one embodiment of the invention in detail, itis to be understood that the invention is not limited in its applicationto the details of construction and the arrangement of the components setforth in the following description or illustrated in the drawings. Theinvention is applicable to other embodiments or of being practiced orcarried out in various ways. Also, it is to be understood that thephraseology and terminology employed herein is for the purpose ofdescription and should not be regarded as limiting.

Reference is now made to FIG. 1, which is a simplified schematic diagramshowing a generalized embodiment of the present invention. In FIG. 1, adatabase 10 is located on a LAN 12. The LAN 12 is protected by afirewall 14, through which external users 16 are able to connect inorder to use the database. External users who successfully negotiate thefirewall, are typically able to make use of the database, and thefirewall is typically able to grant or refuse access to the computer onwhich the database is located. The firewall itself is not able toprovide database protection that is more sophisticated than providingaccess or no access. Thus, according to the present embodiments, thereis provided an additional layer of protection 18, referred tohereinbelow as an SQL filter, which operates regardless of permissionlevels granted by the firewall 14, and which checks passing data packetsfor SQL or other database commands. If it finds database commands thenit uses its own rules, again independent of the firewall, to decidewhether the data packet should be allowed to pass. However, in currentembodiments the system administrator has the responsibility of ensuringthat all incoming packets pass through the filter.

The firewall 14 is shown as a two-part firewall, having a first firewallpart 20, and a second firewall part 22 with a demilitarized zone, (DMZ)24 in between. The demilitarized zone typically includes a web server 26and an application server 28. In one configuration, if it is desired topermit outside users 16 to access database 10 then an application, thatis to say a database client, for using the database, is placed in theDMZ 24. The external user connects to the database client and uses thedatabase client to generate SQL code to access the database. Thus, datapackets directed inwardly from the firewall, and being intended tointerrogate or manipulate the database, may be expected to carry SQL orlike database operating commands. The SQL filter 18 preferably snoopsdata packets passing between the firewall and the LAN, identifies andanalyzes any SQL material in the packets and applies rules to decidewhether the packets may pass or not. The rules are preferablyindependent of those applied by the firewall.

Reference is now made to FIG. 2, which is a representation in blockdiagram form of an embodiment operative in accordance with the presentinvention, and which is similar to the generalized embodiment of FIG. 1,with some minor variations. Parts that are the same as in FIG. 1 aregiven the same reference numerals and are not referred to again exceptas necessary for an understanding of the present embodiments. In FIG. 2the SQL filter 18 is shown to be part of the inner firewall 20. Theserver 26 is shown to support an SQL application and the SQL guardchecks data packets passing the inner firewall and either authorizesthem, in which cases they proceed, or it rejects them, in which case thepackets are dropped. The DMZ 24 carries a database client application26, as before so that an external user may connect to the client in theDMZ and issue database commands. The issued database commands areforwarded to the inner firewall 20.

At the inner firewall 20, which constitutes the entry point to the userorganization's LAN 12, the SQL-filter obtains the traffic to thedatabase, and only such traffic. If other protocols attempt to passthrough SQL-filter they are preferably rejected. The SQL filter assumesthat all data traffic towards the database from the outside is directedthrough the filter by other network devices, and it is theresponsibility of the network administrator to make sure that there isno alternative unsecured path to the database. The filter analyzes thedata stream and finds user names of the externally connecting users, andany SQL statements within the data packets. The proxy holds a securitypolicy, as will be explained in more detail below. The policy comprisesa list of security rules for accepting or rejecting the packets. Therules preferably determine authorization levels on a packet by packetbasis, and may take into account such information as the user name, theSQL commands in the packet (e.g. select, update) and the databaseobjects (e.g. a table name, view name) to which the SQL is applied.

The SQL-filter 20 of the embodiment of FIG. 2 is a proxy to the innerpart of the firewall and receives therefrom notifications on new TCPconnections to the database servers. The filter 20 preferably obtainsall of the data stream of the database server protocol for screening.The SQL-filter may authorize or forbid any database request inaccordance with the rules as currently set, as discussed above.

A currently available prototype is provided as an add-on to Firewall-1by Check Point. Using the OPSEC (Open Platform for Security) by CheckPoint, the firewall is induced to tunnel the relevant data stream to theSQL-filter, which is then able to perform its function of filtering thedatabase commands. The prototype is suitable for any kind of databasesystem, but in particular the MS-SQL Server, Oracle Server, DB2 and UDB)

Reference is now made to FIGS. 3A, 3B and 3C, which are simplifiedserver block diagrams showing the arrangement of FIG. 2 mapped to aseries of servers. In the configuration of FIG. 3A, a first server 40holds the DMZ and the database application, a second server 42 holds theinner firewall and the SQL guard, and a third server 44 holds thedatabase that the application in the first server 40 is intended toquery. The configuration of FIG. 3B is the same as that of FIG. 3Aexcept that the application within the DMZ routes SQL-bearing datapackets to the SQL filter, rather than this being the responsibility ofthe firewall. In FIG. 3C, the firewall once again has the responsibilityof routing SQL-bearing data packets to the filter, however the filteritself is located in the safe zone within the firewall.

The arrangement of FIG. 3 shows the SQL-filter as a stand-alone proxy,whether on the firewall server 42 or within the LAN. In accordance withany of the above configurations, the database, on the database server44, is only able to receive data that has been approved by the filter.

SQL-filters according to various of the present embodiments can analyzedata streams on any relational database technology, e.g. MS-SQL Server,DB2, and UDB by IBM. Filters according to the preferred embodimentsrequire only the following, that a User name or like identification canbe identified, and that requests are sent as SQL statements. Otherembodiments may relate to other systems of database commands and the SQLrequirement may be modified accordingly.

Reference is now made to FIG. 4, which is a simplified diagram showingin greater detail an SQL filter 18 suitable for the embodiments of FIGS.1-3. As discussed above, the filter monitors packets passing through theinner firewall 20, and comprises four internal units, a sessionmanagement unit 50, a packet analyzer 52, an SQL parser 54 and an SQLvalidator 56. The internal units are now considered in turn. First ofall the session management unit 50 performs overall management ofindividual connecting sessions. The session manager is responsible forholding data for each TCP connection or session, including IP addresses,user name, and internal control data, hereinafter referred to as sessiondata. For each incoming packet in the data stream, the session managerassociates the appropriate session data as a context for any SQLstatement contained within the packet.

The packet analyzer 52 analyzes packet content to find SQL text withinthe packet. SQL text is passed to the SQL parser to identify thecommands and the data objects to which it relates, and then all of theinformation obtained is passed on to the SQL validator which determineswhether the commands are authorized for the identified data object forthe user identified in the corresponding session data. For conveniencein the formulation of rules, the rules used by the validator do notusually relate to individual commands or users or data objects butrather to groups of commands, groups of users and groups of objects, aswill be explained in greater detail below.

The packet analyzer 52 is responsible for identifying SQL messages inthe data stream. The TCP connection is a stream-wise connection. HoweverSQL statements, which constitute the database requests, have specificstructure, attributes and length, which may be identified.

The packet analyzer is responsible for isolating the database requestsin the data stream, and then analyzing as follows:

-   -   On initialization—the packet analyzer obtains the source and        target addresses, the protocol version, and the connected user.        This data is placed in the session manager.    -   In the course of the session, the packet analyzer identifies        messages that contain SQL text, including underlying statements        or requests, and isolates the SQL text. The SQL text is passed        to the SQL parser 54 for parsing and authorization checking.

In a further preferred embodiment the packet analyzer also checks othertypes of messages, for example the results of the query. For example itis possible to define the filter to prevent an external user fromdownloading more than a certain number of items from the database. Inthis embodiment, the packet analyzer checks outgoing packets as well asincoming packets.

Database vendors tend to adapt database protocol structures for theirown purposes, as will be discussed in more detail below, and theanalyzer is preferably designed or programmed to accord with theprotocol specification as used by the vendor of the database server inquestion. In a company that uses multiple databases from multiplevendors the analyzer is preferably is able to determine, typically fromthe session manager, which database is being interrogated, and to selectthe correct protocol for use in parsing.

The SQL parser 54 receives data from the packet analyzer 52 as describedabove, and then is responsible for extracting the commands and objectsthat appear in the SQL text within the packets. The parser 54 preferablyoperates by breaking down the text of the SQL messages into underlyingstatements. Individual underlying statements may trigger more than oneauthorization action from the filter. For example a single statement maycontain multiple objects, each needing separate authorization, or thestatement may by its structure require several authorization actions.For example a single statement may gather information from severalsources to be shown in a single view. Each source may be required to beauthorized separately.

In the prototype referred to hereinabove, the SQL parser is based on LEXand YACC technology, which are available both commercially and asfreeware. SQL keywords are treated as tokens and are predefined to theLEX environment. The SQL statement format is likewise defined to the LEXenvironment. Generally SQL definition uses an ANSI standard, howeverindividual vendors tend to make significant modifications, mainly in theDDL (Data Definition Language) part of the language. Individualimplementations preferably follow the database vendor language referenceto ensure that the filter gives full coverage of all the SQL dialect ofthe database being protected, as discussed above in respect of theanalyzer.

While parsing the language the parser collects commands andcorresponding objects from the data stream. Each command and objectcombination is checked immediately, together with the correspondingsession data to determine whether the user is authorized or not for therequested database action defined by the command and object combination.If the user is not authorized, the entire SQL text portion underinvestigation is preferably rejected, and as a further sanction thesession with the user may be ended. Authorizations are checked via theSQL Validator 56, as described below.

The SQL validator 56 receives validation requests from the parser andcarries out validation based on the information supplied by the parser.Validation requests are of the form: is user “SCOTT” allowed to carryout command “SELECT” from data object “EMP”. On each identification ofan SQL command and object in the parsing process, a validation requestis issued to the validator 56.

The validation is carried out using a set of rules arranged in a datastructure which is optimized to enable efficient finding of the highestpriority rule that matches the authorization request. Typically thismeans that the data structure is arranged as a hierarchy.

On initialization, the SQL validator 56 loads a list of rules thatbelong to a currently set policy, and constructs an optimized structuretherefrom. At predetermined intervals, or optionally upon occurrence ofa predefined event, the validator 56 may check whether a new securitypolicy has been set.

Upon receipt of the validation request, the data to be validated ismatched against the optimized structure. The structure allows for rapidselection of the highest priority rule that fits the request. Followingapplication of the appropriate rule, the packet is either allowed topass or is discarded, and the event may be logged. All acts ofdiscarding may be logged, or certain packets regarded as marginallysuspicious may be logged but allowed through, as required by the user.The filter may conveniently make use of the log 58 of the firewall, orof a special log mechanism or of a private log.

The rules that are used are preferably grouped together into sets, andthe sets of rules are the policies referred to herein. Policies can beexchanged to reflect changing security priorities, or for any otherpurpose.

Reference is now made to FIG. 5, which is a simplified diagram showing adialog window 60 for setting up a rule. The dialog window has aplurality of fields for data entry. A policy name field 62 allows therule to be associated with a policy, namely a group of rules. It will beappreciated that a single rule can be featured in a plurality ofpolicies. A second field 64 allows the rule to be given a name, so thatit can be referred to. A third field 66 allows a group of databaseoperation commands to be specified. The database operation commands aretypically SQL commands, e.g. Select, Create Table. The groups arepreferably set in advance by the user for convenience in setting therules. Thus, it may be useful to group database editing commands intoone group, and database management commands into another group.

A fourth field 68 specifies an object or group of objects of thedatabase command. The objects are the database objects referred to bythe database commands, for example an SQL object name, e.g. table name,index name, and even stored procedure, and the group of objects is agroup of such items. A fifth field 70 allows a group of users to bespecified, and a sixth field 72 specifies the action that is to be takenif a data packet fits the rule. Typical actions, as discussed above, areaccepting the packet, rejecting the packet, and an action known as“drop” which comprises both rejecting the packet and terminating thesession, typically a TCP/IP session. A check box 74 allows the user todefine whether the action should be logged.

Two exemplary rules are as follows:Allow, User=SCOTT, Command=SELECT, Object=EMPReject, User=OTHER, Command=CREATE TABLE, Object=N/A

In the above rules individual users and commands are specified. However,it is not expedient to have to specify a separate rule for eachcombination of users and commands and objects. To ease the definition ofrules—a user interface allows the administrator to define groups ofusers, groups of commands and groups of objects. A rule may typically beof the format ‘allow’, <user group>, <command group>, <object group>.The implication is a Cartesian combinations of all members of all thegroups in the rule. It will be appreciated that the scopes of rules maybe extended by the use of additional parameters, such as defining thetime of the day when authorization is allowed.

The rule applies the action defined therein to any data packet thatattempts to pass the filter. The filter is indeed similar to contentfilters used in current firewall technology, the difference being thatthe filter of the present embodiments uniquely looks for and recognizesthe structure of SQL text.

Preferably, the filter is configured so that the default action forunrecognized packets is rejection, so that only those packetsspecifically recognized by a rule are allowed through. The filter thusbehaves as if it has a default rule at the base of the rules hierarchyapplying to all groups of commands, all users and all data objects andwhose action is to reject. Only those packets recognized by a rulehaving an “accept” action higher up in the hierarchy are therefore goingto be accepted. It is possible to change the default behavior by addinga rule at the base of the hierarchy applying to all groups and whoseaction is to reject and log, or reject and deny service.

It is noted that the use of default behavior means that when a newdatabase version is installed, any new commands of the new version arenot initially recognized and are therefore rejected. The filter ispreferably updated with the new commands as soon as possible so that thecommands can be accepted, however, until that happens, the defaultbehavior ensures that modifications of the database do not lead to ahole in the security that the filter provides.

In a further preferred embodiment of the present invention, the analysisof the data packet involves obtaining a signature of the database textfound therein. The rules used by the enforcement module then relate tothe signature.

Reference is now made to FIG. 6, which is a simplified block diagramshowing how a filter system may be configured for a network. Parts thatare the same as those in previous figures are given the same referencenumerals and are not referred to again except as necessary for anunderstanding of the present embodiment. Preferably, the filter systemcomprises two component parts, both of which are configured to worktogether with the network firewall. A first part is a policy editor 80,which located within a firewall management console 82, alongside afirewall management server application 84, and which is placed behindthe firewall 20 in the secure region of the user's internal network. Thesecond part is the filter 18 itself, which is located together with thefirewall 20.

It is noted that in FIG. 6, the accessing client application is locatedexternally, by contrast with the situation shown in FIG. 1, wherein theclient application was located in the DMZ. The location of the clientapplication, which produces the database commands, is not critical tothe present embodiments provided that the data packets produced by theclient program pass the filter 18.

The policy editor 80 allows for rules to be formulated and edited andbuilt into policies which may then be put into operation within thefilter 18. The policy editor also allows for the arrangement of users,data objects and commands into groups, and for subsequent editing of thegroups. The policy editor also allows for editing and arranging ofpolicies themselves, and reference is now made to FIG. 7, which is asimplified diagram showing a policy dialog window. The policy dialogwindow shows a series of rules (rule 1, rule 2 etc) that have beenchosen for inclusion within a policy. Each rule is given a priority, andone of the reasons for giving a priority is that there is no requirementthat the rules are mutually exclusive. Thus, in the event of more thanone rule applying, the filter has to know which rule is to be applied.The order of appearance of the rule in the policy rule defines itspriority. The first rule that is correctly matched with the requestedauthorization, is the one that defines the authorization, and nosubsequent matching is preferably carried out.

Reference is now made to FIG. 8, which is a simplified flow chartshowing the procedure for defining rules and policies. One or moredatabase servers that it is desired to protect are firstly givendefining identities. Secondly, users are defined, and thirdly groups aredefined, and individual users are assigned to the groups. Optionallyexternal connecting locations can be defined as trusted locations. Theskilled person will appreciate that users are most effectively groupedaccording to access level requirements and security issues raised.Fourthly, the database command groups are assigned and individualcommands are assigned to the groups. Fifthly, database objects aredefined. Sixthly object groups are defined and the individual objectsare assigned to groups. Finally individual rules are defined byspecifying an object group, a user group and a command group andassigning an action thereto. The action can be modified by furtherdefining whether it should be tracked or logged. Policies may then bedefined by selecting rules into a hierarchy, and finally a mostappropriate policy is selected for current use by the filter.

The embodiment described herein preferably provides a security layer,additional to that of the firewall, for protecting databases byfiltering and monitoring SQL requests that are generated outside of thedatabase server's local area network. The preferred embodiments scan allTCP/IP packets that are to be delivered to the database server, trackingeach database command and authorizing or rejecting each command, basedon a table of one or more policies, each comprising a set of rules, andwhich may be provided by the user, or which may be supplied as defaults.The policies establish which users can have access to the database,which commands they can use, and for which data objects in the database.It is noted that only one policy may be active at one time. Multiplepolicies are allowed within the system, but for different SQL-filterlocations or different policies for different days. The latter may bedesirable for example to permit remote maintainance on a specific day inthe month.

The SQL-filter adds an additional layer of security to a database ordatabase system by checking SQL statements that cross the firewall fromexternal networks. Such statements are requied by the filter to conformto authorization policies set by the system administrator to ensure thatsecurity breaches, such as compromised database passwords, misconfigureddatabase security, database vulnerabilities etc. cause minimal damage.Using the present embodiments, it is possible to give a user a certainlevel of access when connecting within the organization, however torestrict his database access when connecting from outside of theorganization. Thus any given user may connect from the outside and carryout non-database functions as he chooses. However, as soon as heattempts to carry out database access functions then the filter can beused to limit his activity independently of the firewall. It is thuspossible to assign users with full rights to a database when connectinginternally, and to assign to the same users full rights to connect fromoutside, and additionally, in accordance with the present embodiments tospecifically restrict database access to any desired extent for anygiven user when connecting from the outside. Prior art firewalls areable to define that certain machines (identified by IP address) do nothave access to computers that store the database but do not in factinspect for or in any way restrict actual database usage.

Thus, the policies that can be set by the SQL-filter enable the systemadministrator to differentiate between access permissions granted tousers when working locally and permissions they may be assigned whenworking externally. In addition, it is possible to use the informationheld in incoming data packets to determine where the external connectioncomes from. Thus certain external machines can be predefined as safemachines, or safe machines for given users. Policies, which are setbased on user's id, SQL commands, and database objects, can thus alsoincorporate connecting locations.

The SQL-filter of the preferred embodiments thus preferably protects thedatabases within the LAN from unauthorized external access and ensuresthat unauthorized access attempts do not cross the firewall.

It is appreciated that certain features of the invention, which are, forclarity, described in the context of separate embodiments, may also beprovided in combination in a single embodiment. Conversely, variousfeatures of the invention which are, for brevity, described in thecontext of a single embodiment, may also be provided separately or inany suitable subcombination.

Unless otherwise defined, all technical and scientific terms used hereinhave the same meanings as are commonly understood by one of ordinaryskill in the art to which this invention belongs. Although methodssimilar or equivalent to those described herein can be used in thepractice or testing of the present invention, suitable methods aredescribed herein.

All publications, patent applications, patents, and other referencesmentioned herein are incorporated by reference in their entirety. Incase of conflict, the patent specification, including definitions, willprevail. In addition, the materials, methods, and examples areillustrative only and not intended to be limiting.

It will be appreciated by persons skilled in the art that the presentinvention is not limited to what has been particularly shown anddescribed hereinabove. Rather the scope of the present invention isdefined by the appended claims and includes both combinations andsubcombinations of the various features described hereinabove as well asvariations and modifications thereof which would occur to personsskilled in the art upon reading the foregoing description.

1. A security filter device for protection of database objects from unwanted access comprising: a data packet inspection unit for inspecting passing data packets to find and carry out an analysis of database operation text within said packet, and an enforcement unit, associated with said data packet inspection unit for applying enforcement rules to said data packet, based at least partly on said analysis, the enforcement unit operable to protect respective database objects.
 2. The security filter device according to claim 1, wherein said data inspection unit comprises: a packet analysis unit to look for structure associated with database operation text, and a parsing unit, associated with said search unit to parse said database operation text into underlying statements comprising at least database operation commands and database objects.
 3. The security filter device according to claim 1, wherein said data packet inspection unit is configurable in association with a firewall between an external network and an internal LAN containing said database objects, thereby to guard a respective database.
 4. The security filter device according to claim 1, wherein said inspection unit is configurable to be positioned between two LANs.
 5. The security filter device according to claim 1, wherein said data packet inspection unit is further operable to find information regarding sources of respective data packets and regarding data objects of respective commands.
 6. The security filter device according to claim 5, wherein said enforcement rules each comprise at least one condition, said condition being the presence in the database operation text of a predetermined database operation command.
 7. The security filter device according to claim 5, wherein said enforcement rules each comprise at least one condition, said condition being the presence in the database operation text of any one of a group of database operation commands belonging to a preformulated group.
 8. The security filter device according to claim 5, wherein said wherein said enforcement rules each comprise at least one condition, said condition being the specification within the database operation text of a predetermined database object.
 9. The security filter device according to claim 5, wherein said enforcement rules each comprise at least one condition, said condition being the specification within the database operation text of any one of a group of database objects belonging to a preformulated group.
 10. The security filter device according to claim 1, further comprising a management module for setting said enforcement rules.
 11. The security filter device according to claim 10, wherein said management module is further operable to define groups of database commands, said groups being usable to define said rules.
 12. The security filter device according to claim 10, wherein said management module is accessible via a graphical user interface.
 13. The security filter device according to claim 12, wherein said management module is operable to set an access policy comprising a plurality of rules, each rule specifying a group of commands, a group of users and a group of data objects, said access policy being transferable to said rule application unit.
 14. The security filter device according to claim 1, wherein at least some of said enforcement rules define logging activities and said enforcement unit further comprises logging functionality therefore.
 15. The security filter device according to claim 1, wherein said inspecting comprises obtaining a signature from said database operation text and wherein at least some of said rules relate at least in part to said signatures.
 16. A method for protection of database objects from unwanted access comprising: parsing a data packet to find database operation commands in said packet, and applying enforcement rules to said data packet, the enforcement rules specifying conditions based at least partially on said database operation commands, and operative to protect the respective database objects.
 17. The method according to claim 16, further comprising finding information regarding sources of respective data packets and regarding data objects of respective commands.
 18. The Method according to claim 17, wherein said finding information regarding sources of respective data packets is carried out per user connection, the method further comprising associating said sources with data packets of said user connection.
 19. The Method according to claim 17, further comprising applying said enforcement rules selectively to said data packets, depending on information found in respective data packets by said parsing units.
 20. The Method according to claim 19, wherein said database operation commands are arranged in groups and wherein said rules relate to said groups.
 21. The Method according to claim 20, wherein said command sources are arranged in groups and said rules relate to said groups.
 22. The Method according to claim 21, wherein said database objects are arranged in groups and wherein said rules relate to said groups.
 23. The Method according to claim 16, further comprising arranging said database commands into groups and using said groups to define said rules.
 24. The Method according to claim 23, further comprising forming an access policy by arranging together a plurality of rules for use.
 25. The method of claim 16 wherein parsing further comprises identifying data packets corresponding to a data access transaction conformant to a predetermined data access protocol.
 26. The method of claim 25 wherein the data access transaction is indicative of statements corresponding to the database operation commands, further comprising interpreting the statements and comparing the statements to rules operable to indicate allowability of the data access transaction.
 27. The method of claim 26 wherein the statements correspond to SQL text according to SQL syntax.
 28. The security filter device according to claim 1, wherein said data packet inspection unit is operable as an addressable node having a node address, the node address recognized by the external network. 